프로세스

프로세스는 실행 중인 프로그램(특정 매체에 저장된 오브젝트 코드)
하지만 프로세스는 사용 중인 파일, 대기 중인 시그널, 커널 내부 데이터, 프로세서 상태, 하나 이상의 물리적 메모리 영역이 할당된 메모리 주소 공간, 실행 중인 하나 이상의 스레드 정보, 전역 데이터가 저장된 데이터 부분 등 모든 자원을 포함하는 개념

사실상 프로세스는 프로그램 코드를 실행하면서 생기는 모든 결과물

커널은 이 모든 세부 사항을 투명하고 효율적인 방식으로 관리해야 함

실행 중인 스레드(보통 줄여서 스레드라 칭하는)는 프로세스 내부에서 동작하는 객체
각 스레드는 개별적인 프로그램 카운터와 프로세스 스택, 프로세서 레지스터를 가지고 있음

커널은 프로세스가 아니라 이러한 각각의 스레드를 스케줄링 함

전통적인 유닉스 시스템 : 프로세스가 하나의 스레드로 구성
현대 시스템 : 여러 개의 스레드로 구성된 다중 스레드 프로그램 만연

리눅스는 독특한 방식으로 스레드 구현
리눅스는 프로세스와 스레드 구분 안함
리눅스에서 스레드는 조금 특별한 형태의 프로세스일 뿐

현대 운영체제에서 프로세스는 가상 프로세서와 가상 메모리라는 두 가지 가상 환경 제공
가상 프로세서는 실제로 수백 개의 프로세스가 프로세서를 공유하는 상황이라도, 프로세스가 혼자 시스템을 사용하는 듯한 가상 환경 제공
가상 메모리는 프로세스가 시스템의 전체 메모리를 혼자 차지하고 있는 것처럼 메모리를 할당하고 관리할 수 있게 해줌

스레드는 각자 고유한 가상 프로세서를 할당받지만 가상 메모리는 공유함

프로그램 자체는 프로세스가 아님
프로세스는 작동 중인 프로그램 및 그와 관련된 자원을 뜻함
같은 프로그램 실행하는 둘 이상의 프로세스 존재 가능
여러 프로세스가 같이 파일 사용, 주소 공간 등의 자원 공유 가능

프로세스는 생성되면서 생을 시작
리눅스에서는 기존 프로세스를 복사해서 새 프로세스를 만드는 fork() 시스템 호출을 통해 프로세스가 만들어짐
fork()를 호출하는 프로세스는 부모 프로세스, 새로 만들어진 프로세스는 자식 프로세스가 됨
부모 프로세스는 fork() 시스템 호출이 반환된 지점에서 실행을 계속, 자식 프로세스도 같은 위치에서 실행 시작
즉, fork() 시스템 호출은 부모 프로세스에서 한 번, 자식 프로세스에서 한 번, 총 두 번 반환이 일어남

대개의 경우 fork한 직후 다른 새 프로그램 실행
exec() 계열의 함수를 호출해 새로운 주소 공간 만들고 새 프로그램 불러들일 수 있음
리눅스 커널의 fork() 시스템 호출은 실제로는 clone() 시스템 호출을 이용해 구현됨

프로그램은 exit() 시스템 호출을 통해 종료됨
이 함수는 프로세스를 종료하고 프로세스의 모든 자원 반납
부모 프로세스는 특정 프로세스가 종료할 때까지 기다리는 wait4() 시스템 호출을 이용해 자식 프로세스의 종료 상태 확인 가능

• 커널이 구현하는 것은 wait4() 시스템 호출. 리눅스 시스템은 C 라이브러리를 통해 일반적인 wait(), waitpid(), wait3(), wait4() 함수를 제공함. 각 함수는 조금씩 다르지만 모두 종료된 프로세스의 상태 정보 제공함
• 프로세스를 다른 말로 태스크(task, 작업)라고도 부름. 리눅스 커널 내부에서는 프로세스를 태스크라고 부르는 경우 많음. 보통 커널 관점에서 프로세스 지칭 시 태스크라는 용어 사용

프로세스 서술자와 태스크 구조체

커널은 프로세스 목록을 태스크 리스트라고 부르는 환형 양방향 연결 리스트 형태로 저장(태스크 배열로 부르는 경우도 있지만 연결 리스트이므로 태스크 리스트가 적절)
태스크 리스트의 각 항목은 <linux/sched.h>에 정의된 struct task_struct 형식으로 되어 있으며, 프로세스 서술자라고 부름
프로세스 서술자에는 해당 프로세스와 관련된 모든 정보가 들어 있음

task_struct 구조체는 32비트 시스템에서 약 1.7KB의 상당히 큰 구조체
커널이 프로세스를 관리하는데 필요한 모든 정보를 가지고 있다는 점을 감안 시 이 크기는 작은 것

프로세스 서술자에는 사용 중인 파일, 프로세스의 주소 공간, 대기 중인 시그널, 프로세스의 상태 등 실행 중인 프로그램을 설명하는 많은 정보가 들어 있음

프로세스 서술자의 할당

task_struct 구조체는 객체 재사용 및 캐시 컬러링 기능을 지원하는 슬랩 할당자slab allocator를 사용해 할당

2.6 커널 이전에는 task_struct 구조체를 각 프로세스의 커널 스택 끝 부분에 저장했음
(이렇게 하면 x86처럼 레지스터가 적은 아키텍처에서는 구조체 위치를 저장하는 레지스터를 별도로 사용하지 않고도 스택 포인터 통해 프로세스 서술자 위치 계산 가능했었음)
이제는 슬랩 할당자 이용 동적으로 프로세스 서술자 만들기 때문에 thread_info라는 새로운 구조체를 스택이 아래쪽으로 확장 시 스택 밑바닥, 위쪽으로 확장 시 스택 꼭대기에 대신 둠

• 레지스터 부족 시스템 위해서만 아니라 thread_info 구조체 사용으로 어셈블리 코드에서 사용하는 값 오프셋 계산을 쉽게 할 수 있도록 함

각 태스크의 thread_info 구조체는 프로세스 스택의 제일 끝부분에 할당됨
구조체의 task 포인터가 태스크의 실제 task_struct 구조체를 가리킴

프로세스 서술자 저장

시스템은 고유한 프로세스 인식 번호(PID)를 이용해 프로세스 구별함
PID는 pid_t라는 부정형opaque의 숫자 값으로, 보통은 실제로 int 형 사용함
하지만 초기 유닉스 및 리눅스와의 하위 호환성 문제로 PID 최대값은 기본적으로 (short int 최대값인) 32,768이며, 이 값은 선택적으로(<linux/thread.h> 파일을 통해) 400만으로 상향 조정 가능
커널은 PID 값을 프로세스 서술자의 pid 항목에 저장

• 부정형은 실제 물리적인 표현형 알려지지 않았거나 실제 표현형 노출할 필요 없을 때 사용하는 형이다.

근본적으로 PID 최대값은 시스템에 동시에 존재할 수 이쓴 최대 프로세스 수
일반 데스크탑 시스템은 32,768개 충분하지만, 대용량 서버에서는 더 많은 프로세스 필요할 수 있음
최대값이 낮을수록 상항을 넘어 다시 낮은 PID값 할당되는 상황 빨리 돌아옴
=> 이 경우 나중에 만든 프로세스 PID가 큰 값을 갖는다는 유용한 정보 사라짐

오래된 애플리케이션과의 호환성 고려할 필요 없다면, 시스템 관리자가 /proc/sys/kernel/pid_max 값 수정해 최대값 증가 가능

커널 내부에서 태스크에 접근할 때 보통 task_struct 구조체의 포인터를 사용함
따라서 현재 실행 중인 태스크의 프로세스 서술자를 빠르게 찾는 방법 필요 => current 매크로가 이 역할을 함

current 매크로 : 아키텍처별로 다른 방식으로 구현됨
어떤 아키텍처는 현재 실행 중인 프로세스의 task_struct 포인터를 레지스터에 저장해 두고 접근하는 효율적인 방식을 쓸 수 있음
(레지스터를 아껴야 하는)x86 같은 아키텍처에서는 thread_info 구조체가 커널 스택에 저장된다는 사실을 이용해 thread_info 구조체의 위치를 계산해내고, 이를 통해 task_struct의 위치 알아냄

x86의 current 매크로는 스택 포인터의 하위 13비트를 덮어쓰는 방식으로 thread_info 구조체 위치 계산해냄
current_thread_info() 함수가 이 역할을 담당함

movl $-8192, %eax
andl %esp, %esp

이 코드는 스택 크기가 8KB라고 가정함. 4KB 스택 사용 시 8192 대신 4096을 사용.

마지막으로, 이 current 매크로는 thread_info의 항목을 참조해 task_struct 구조체를 반환

current_thread_info()->task;

IBM의 RISC기반 PowerPC에서는 이와 다른 방식 사용하는데, 레지스터에 현재 task_struct 포인터를 저장하는 방식 사용함
따라서 PPC에서 current 매크로는 r2 레지스터에 저장된 값을 반환하기만 하면 된다.
프로세스 서술자에 접근하는 것은 매우 빈번하고 중요한 작업이기 때문에 이를 별도 레지스터를 할당할 만한 작업이라고 판단했기 때문

프로세스 상태

프로세스 서술자의 state 항목은 현재 프로세스가 처한 환경을 알려줌
시스템의 프로세스는 정확히 다섯 가지 상태 중 하나에 있음
각 상태값은 다음 다섯 가지 플래그를 이용해 표현

• TASK_RUNNING - 프로세스가 실행 가능한 상태. 현재 실행 중이거나 실행되기 위해 실행 대기열에 있는 상태. 사용자 공간에서 실행된 프로세스는 이 상태만 가질 수 있음. 커널 공간에서 실행 중인 프로세스도 이 상태에 속함.
• TASK_INTERRUPTIBLE - 프로세스가 특정 조건이 발생하기를 기다리며 쉬는 중임(중단). 기다리는 조건이 발생하면 커널은 프로세스의 상태를 TASK_RUNNING으로 바꾼다. 프로세스가 시그널을 받은 경우에는 조건에 상관없이 실행 가능한 상태로 바뀜.
• TASK_UNINTERRUPTIBLE - 시그널을 받아도 실행 가능 상태로 바뀌지 않는 점 제외하면 TASK_INTERRUPTIBLE 상태와 같음. 이 상태는 프로세스가 방해받지 않고 특정 조건을 기다려야 하는 경우, 기다리는 조건이 금방 발생하는 경우에 사용. 이 상태에 있는 태스크는 시그널에 응답 안 하므로(이것 때문에 ps(1) 명령 결과에 D 상태로 ㅍ시되는 죽일 수 없는 프로세스가 등장하는 이유. 작업이 시그널에 응답 안 하므로 SIGKILL 시그널 보낼 수 없음. 게다가, 작업 종료가 가능해도 중요한 동작을 수행 중이거나 세마포어 사용 작업일 수 있으므로 종료 안 하는 것이 바람직), 이 플래그는 TASK_INTERRUPTIBLE만큼 자주 사용 안 함.
• __TASK_TRACED - 디버거 등의 다른 프로세스가 ptrace를 통해 해당 프로세스를 추적하는 상태
• __TASK_STOPPED - 프로세스 실행이 정지된 상태. 해당 태스크는 실행 중이지도 않고 실행 가능한 상태도 아님. 작업이 SIGSTOP, SGTSTP, SIGTTIN, SIGTTOU 같은 시그널을 받은 경우 디버그 중에 시그널을 받은 경우에 이 상태가 이 상태가 됨.

현재 프로세스 상태 조작

커널 코드에서 프로세스의 상태를 바꿀 필요가 생기는 경우 많음.
다음 함수를 사용하기를 권장

set_task_state(task, state); // 태스크 'task'의 상태를 'state' 상태로 설정

이 함수는 특정 태스크의 상태를 지정한 상태로 변경. 그리고 필요한 경우, 이 함수는 메모리 보호 기능 이용 다른 프로세서와 작업 순서 겹치는 것 방지(대칭형 다중 프로세스 시스템에서 이 기능 필요).

대칭형 다중 프로세스 시스템 경우 고려할 것을 빼면 이 함수는 다음 동작을 함

task->state = state;

set_current_state(state) 함수는 set_task_state(current, state) 함수와 같음.
해당 함수 구현은 <linux/sched.h> 참고

프로세스 컨텍스트

프로세스의 중요한 부분 중 하나는 실행 중인 프로그램 코드
실행 파일에서 이 코드를 읽어 들이고, 프로그램 주소 공간에서 코드 실행함
일반적인 프로그램은 사용자 공간에서 실행됨
프로그램이 시스템 호출을 사용하거나 예외 처리 발생 시, 프로그램은 커널 공간으로 진입함
이런 상황을 커널이 '프로세스를 대신해 실행 중' 또는 '커널이 프로세스 컨텍스트에 있음'이라고 함
프로세스 컨텍스트에 있을 때 current 매크로 사용 가능
그 사이에 우선순위가 높은 프로세스가 실행 가능한 상태가 되어 스케줄러가 그 프로세스 먼저 실행하지 않으면, 커널이 작업 끝내면 프로세스는 사용자 공간에서 실행 계속함

시스템 호출과 예외 처리기는 잘 정의된 커널 진입 인터페이스임
프로세스는 이 두 가지 인터페이스 중 하나를 통해 커널 공간에 들어갈 수 있음
즉, 커널에 대한 접근은 이 두 인터페이스를 통해야만 함

프로세스 계층 트리

유닉스 시스템처럼 리눅스도 프로세스 간 독특한 계층 구조 존재
모든 프로세스는 PID가 1인 init 프로세스의 자손임
init 프로세스는 부트 과정의 최종 단계에서 커널이 실행하는 프로세스임
그 다음 init 프로세스는 시스템의 초기화 스크립트를 읽어 더 많은 프로그램 실행시켜 부트 과정 완료함

시스템의 모든 프로세스는 정확히 하나의 부모 프로세스를 가짐
또한 모든 프로세스는 하나 이상의 자식 프로세스를 가질 수 있음
같은 부모 프로세스를 가지는 자식 프로세스를 형제 프로세스sibling라고 부름
프로세스간의 관계는 프로세스 서술자에 저장됨
각 task_struct 구조체에는 부모의 task_struct를 가리키는 parent라는 포인터와 자식의 task_struct 리스트를 가리키는 children 포인터가 들어 있음

현재 프로세스에 대해 다음과 같은 코드를 이용 시 부모 프로세스의 프로세스 서술자 얻기 가능

struct task_struct *my_parent = current->parent;

다음과 같은 코드로 프로세스의 모든 자식 프로세스에 접근 가능

struct task_struct *task;
struct list_head *list;

list_for_each(list, &current->children) {
	task = list_entry(list, struct task_struct, sibling);
	// 이제 task는 현재 프로세스의 자식 프로세스 중 하나를 가리킴 
}

init 태스크의 프로세스 서술자는 init_task라는 이름으로 정적으로 할당됨

다음 코드는 모든 프로세스 사이의 관계를 보여줌

struct task_struct *task;

for (task = current; task != &init_task; task = task->parent)
	;
// task가 init을 가리킬 때까지 반복

프로세스 계층 구조 이용 시 시스템의 어떤 프로세스에서도 다른 특정 프로세스 찾아갈 수 있음
시스템의 모든 프로세스를 훑고 싶을 때에는 작업(태스크) 리스트가 환형 양방향 리스트이므로 매우 쉽게 작업 가능

어떤 태스크가 주어졌을 때 리스트에서 다음 태스크를 얻기 위해서는 다음 코드를 실행하면 됨

list_entry(task->tasks.next,  struct task_struct, tasks)

이전 태스크를 얻기 위해서는 다음 코드 실행

list_entry(task->tasks.prev,  struct task_struct, tasks)

위 두 가지 루틴은 next_task(task)와 prev_task(task)라는 매크로로 제공됨

전체 태스크 열거하는 for_each_process(task) 매크로(반복 단계마다 task 포인터는 리스트의 다음 태스크 가리킴)

struct task_struct *task;

for_each_process(task) {
	// 매크로의 각 반복마다 각 태스크의 이름과 PID 출력됨
	printk("%s[%d]\n", task->comm, task->pid);
}

모든 태스크 열거하는 일은 매우 부하가 큰 작업임

프로세스 생성

대부분 OS는 스폰spawn 방식으로 새로운 주소 공간에 새 프로세스 만들고, 실행 파일 읽은 후 그 코드를 실행하여 프로세스 생성

유닉스는 독특하게 이 과정을 fork()와 exec()이라는 두 함수로 분리

• 여기서 exec() 함수는 exec() 함수 군을 일컬음. 커널은 execve() 시스템 호출을 바탕으로 execlp(), execle(), execv(), execvp() 함수를 구현함.

먼저 fork()는 현재 태스크를 복제해 자식 프로세스를 만듦
이렇게 만들어진 프로세스는 (고유값을 갖는)PID와 (부모 프로세스 PID인)PPID, 상속되지 않는 지연된 시그널과 같은 일부 자원과 통계 수치 제외하고는 부모와 같은 값을 가짐
다음 함수인 exec()은 새로운 실행파일을 주소 공간에 불러오고 이를 실행
fork() 다음에 exec()을 실행하는 조합은 대부분 OS에서는 하나의 함수로 제공

Copy-on-Write

전통적인 fork()는 부모 프로세스의 모든 자원 복사해 자식 프로세스에게 넘겨줌
이런 방식은 공규 가능한 많은 데이터를 복사하므로 단순하고 비효율적
게다가 새로 만든 프로세스가 바로 다른 프로그램 실행하는 경우 복사 작업이 모두 헛수고가 됨
리눅스에서는 'copy-on-write(기록사항 발생 시 복사)' 페이지를 이용해 fork() 함수 구현했음
기록사항 발생 시 복사COW, Copy-on-Write 기능은 데이터 복사를 지연 또는 방지하는 기능임
프로세스 주소 공간을 복사하는 대신 부모와 자식 프로세스가 같은 공간 공유함

그러나 기록사항 발생해 데이터 변경 필요 시 그 순간 사본을 만들어 각 프로세스가 별도의 내용 가지게 됨
따라서 리소스 복사는 해당 리소스에 대한 기록이 발생하는 경우에만 일어남
그때까지는 읽기전용 상태로 공유 가능
이 기법은 주소 공간에 실제 기록 작업 일어날 때까지 각 페이지의 복사 작업을 지연시킴
프로세스가 절대 기록을 하지 않는 경우, e.g. fork() 직후에 exec() 함수가 호출되는 경우에는 복사가 필요 없어짐

fork() 함수가 해야 할 일은 프로세스의 페이지 테이블을 복사하는 것, 자식 프로세스용 프로세스 서술자를 만들어 주는 것뿐임
일반적으로 프로세스는 생성된 다음 다른 실행파일 실행하므로, 이 같은 최적화를 통해 많은 데이터 복사 낭비를 막음
유닉스의 철학인 빠른 프로세스 실행에 부합

프로세스 생성

리눅스는 clone() 시스템 호출 이용 fork() 구현
clone() 시스템 호출은 다양한 플래그 사용해 부모와 자식 프로세스간 공유가 필요한 자원 지정
fork(), vfork(), __clone() 라이브러리 함수는 각자 적절한 플래그 사용해 clone()을 호출함
clone() 시스템 호출은 다시 do_fork() 함수를 호출

실제 프로세스 생성 작업은 kernel/fork.c에 정의된 do_fork() 함수에서 처리함
이 함수는 copy_process() 함수 호출하고 프로세스 실행을 시작함
copy_process() 함수가 하는 일은 다음과 같음

1. dup_task_struct() 함수를 호출해 커널 스택 새로 만들고, 새 프로세스용 thread_info, task_struct 구조체 만듦. 새로 만들어진 데이터의 값은 현재 태스크와 동일함. 이 시점에 부모와 자식 프로세스의 프로세스 서술자는 같음.
2. 새로 만든 자식 프로세스로 인해 현재 사용자의 프로세스 개수 제한을 넘어가지 않는지 확인.
3. 이제 자식 프로세스를 부모와 구별해야 함. 프로세스 서술자의 다양한 항목의 값을 초기화함. 프로세스 서술자에서 부모 프로세스의 값을 물려받지 않는 항목은 주로 통계 정보. 대부분의 task_struct 항목 값은 바뀌지 않음.
4. 자식 프로세스의 상태를 TASK_UNINTERRUPTIBLE로 설정해 아직 실행되지 않게 함.
5. copy_process()는 copy_flag() 함수를 호출해 task_struct 구조체의 flags 내용을 정리함. 작업이 관리자 권한을 가지고 있음을 뜻하는 PF_SUPERPRIV 플래그를 초기화함. 프로세스가 exec() 함수를 호출하지 않았음을 뜻하는 PF_FORKNOEXEC 플래그를 설정함.
6. alloc_pid() 함수를 호출해 새로 만든 태스크에 새로운 PID 값을 할당함.
7. clone() 함수에 전달된 플래그 값에 따라 copy_process()는 열린 파일 및 파일시스템 정보, 시그널 핸들러, 프로세스 주소 공간, 네임스페이스namespace 등을 복제하거나 공유함. 보통 스레드 사이에서는 이런 자원을 공유하며, 그 외의 경우에는 개별적으로 사용하므로 이 단계에서 복제함.
8. 마지막으로 copy_process()는 나머지 정리 작업을 수행하고 호출한 쪽에 새로 만든 자식 프로세스의 포인터를 반환함.

do_fork()로 반환되어 돌아오면 copy_process()가 성공한 경우에 새로 만든 자식 프로세스를 깨워서 실행함
커널은 의도적으로 자식 프로세스를 먼저 실행함(제대로 동작 안 되는 경우 있음)
일반적으로 자식 프로세스는 바로 exec() 함수 호출하므로, 부모 프로세스가 먼저 실행될 시 주소 공간에 쓰기 작업이 생겨 발생하는 COW 작업 막을 수 있음

vfork()

vfork() 시스템 호출은 부모 프로세스의 페이지 테이블을 복사하지 않는다는 점만 빼면 fork()와 똑같이 동작함
대신 자식 프로세스는 부모 프로세스의 주소 공간 속에서 별개의 스레드 형태로 실행되고, 부모 프로세스는 자식 프로세스가 exec()을 호출하거나 종료할 때까지 대기함
자식 프로세스는 주소 공간의 내용을 바꿀 수 없음
COW를 이용해 fork()를 구현할 수 없었던 옛날 3BSD 시절 상당히 좋은 최적화 기법이었음
2.6 버전 기준 COW, 자식 프로세스 우선 실행 방식을 사용하기 때문에, vfork() 사용으로 얻을 수 있는 이점은 부모 프로세스의 페이지 테이블 복사 안 하는 것뿐임
리눅스 페이지 테이블 항목에 대해서도 COW 기능 제공 시 이 장점도 사라짐
vfork()의 작동 방식 상당히 까다로움(e.g. exec() 실패 시 대처 방법?) 이상적인 시스템이라면 vfork() 필요 없음으로 커널에서 꼭 이를 구현 안 해도 됨
일반적인 fork() 이용해 vfork() 구현해도 문제 없음, 실제로 2.2 버전 커널까지 이 방식 사용

vfork() 시스템 호출은 clone() 시스템 호출에 특별한 플래그를 지정해 구현함

1. copy_process()에서 task_struct의 vfork_done 항목을 NULL로 설정함.
2. 특별한 플래그가 지정된 경우 do_fork()에서 vfork_done 포인터가 특정 주소를 가리키도록 함.
3. 부모 프로세스는 자식 프로세스를 우선 실행시킨 다음 반환하지 않고 자식 프로세스가 vfork_done 포인터 이용해 신호를 보낼 때까지 대기.
4. 태스크가 메모리 주소 공간을 반환할 때 호출되는 mm_release() 함수에서 vfork_done 포인터가 NULL인지 아닌지 확인함. NULL이 아니면 부모 프로세스에 신호 보냄.
5. do_fork() 함수로 돌아가서 부모 프로세스 깨우고 반환함.

계획대로 진행 시 자식 프로세스는 새 주소 공간에서 실행되고, 부모 프로세스는 원래 주소 공간에서 실행됨
부담은 적지만 깔끔한 구현은 아님

리눅스의 스레드 구현

스레드는 널리 쓰이는 현대적 프로그래밍 기법
스레드를 이용해 메모리 주소 공간을 공유하는 같은 프로그램 여러 개 동시에 실행 가능
스레드는 사용 중인 파일 및 기타 자원을 공유함
스레드를 통해 동시 프로그래밍concurrent programming이 가능해지고, 다중 프로세서 시스템에서는 진정한 병렬처리를 구현 가능함

리눅스는 독특한 스레드 구현 방식 가짐
리눅스 커널에는 별도의 스레드 개념 없음
기본적인 프로세스로 모든 스레드를 구현

리눅스 커널은 스레드를 위한 별도의 자료구조, 특별한 스케줄링 기법 없음
리눅스의 스레드는 특정 자원을 다른 프로세스와 공유하는 특별한 프로세스일 뿐
각 스레드는 별도의 task_struct 구조체 가짐, 커널 입장에서 주소 공간과 같은 자원을 다른 프로세스와 공유하고 있는 정상적인 프로세스

스레드에 대한 이런 접근 방식은 윈도우나 솔라리스처럼 커널에서 별도의 스레드(lightweigh process=경량 프로세스라 부르기도 함)를 지원하는 방식과 크게 다름
경량 프로세스라는 이름이 시스템간 철학적 차이 보여줌
리눅스 외 다른 OS에서 스레드는 무거운 프로세스에 비해 가볍고 빠륵 실행하는 기능을 제공하는 무언가
리눅스에서는 다른 프로세스와 자원을 공유하는(이미 충분히 경량화된) 프로세스에 불과함
e.g. 네 개의 스레드로 구성된 프로세스 경우
리눅스 : 네 개의 프로세스에 각각 네 개의 프로세스 서술자, 프로세스간 일부 자원 공유
다른 OS : 하나의 프로세스 서술자 안에 네 개의 스레드 가리키는 정보, 주소 공간이나 사용 중인 파일 등 공유 자원 정보는 서술자 내에 존재
=> 리눅스가 매우 명쾌한 구조

스레드 생성

스레드는 정상적인 태스크와 마찬가지 방식으로 만들어짐
다만, clone() 시스템 호출 시 특정 자원 공유하도록 플래그 지정해줌

clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0);

위의 코드는 주소 공간, 파일시스템 자원, 파일 서술자, 시그널 핸들러 공유한다는 점 제외하면 정상적 fork() 시스템 호출과 결과가 같음
즉, 새 태스크와 그 부모 프로세스는 흔히 말하는 스레드 관계가 됨

반면, 일반적인 fork()는 다음과 같은 방식으로 구현됨

clone(SIGHAND,0);

vfork()는 다음과 같이 구현됨

clone(CLONE_VFORK | CLONE_VM | SIGCHLD, 0);

clone()에 넘겨주는 플래그를 통해 새로운 프로세스의 동작을 정의
부모 프로세스와 자식 프로세스간에 공유할 자원을 자세히 지어함
clone에서 사용하는 플래그는 <linux/sched.h>에 정의되어 있음

clone()의 시스템 호출 플래그

커널 스레드

커널도 일부 동작을 백그라운드에서 실행하는 것이 좋을 때가 있음
커널 공간에서만 존재하는 표준 프로세스인 커널 스레드 이용해 이런 작업 가능
커널 스레드와 정상 프로세스간 주요 차이점은 커널 스레드에는 주소 공간이 없다는 점(프로세스 주소 공간 가리키는 mm 포인터가 NULL임)
커널 스레드는 커널 공간에서만 동작하며 사용자 공간으로 컨텍스트 전환 안 일어남
하지만 정상 프로세스와 마찬가지로 커널 스레드도 스케줄링되며 선점 가능

리눅스는 일부 작업을 커널 스레드를 통해 처리함
대표적으로 flush 및 ksoftirqd 작업이 있음
ps -ef 명령 이용하면 리눅스 시스템의 커널 스레드 확인 가능
커널 스레드는 매우 많음
커널 스레드는 시스템 부팅 시 다른 커널 스레드에 의해 만들어짐
커널 스레드는 다른 커널 스레드를 통해서만 만들 수 있음
리눅스는 kthreadd 커널 프로세스가 모든 커널 스레드를 만드는 방식으로 커널 스레드 관리함

새 커널 스레드 만들려면 <linux/kthread.h>에 정의된 다음 인터페이스 사용

struct task_struct *kthread_create(int (*threadfn) (void *data), void *data, const char namefmt[], ...)

kthread 커널 프로세스는 clone() 시스템 호출을 이용해 새 태스크를 만듦
새로 만들어진 프로세스는 data 매개변수를 통해 전달된 threadfn 함수를 실행함
새 프로세스는 printf 스타일로 여러 개의 매개 변수로 형식화한 namefmt 문자열에 해당하는 이름 가짐
처음 프로세스는 실행할 수 없는 상태로 만들어짐
wake_up_process() 함수를 통해 명시적으로 깨워주지 않으면 실행되지 않음
kthread_run() 함수를 이용하면 실행 가능한 프로세스를 바로 만들 수 있음

struct task_struct *kthread_run(int (*threadfn) (void *data), void *data, const char namefmt[], ...)

이 함수는 매크로로 구현되었고, kthread_create()와 wake_up_process()를 호출하는 단순한 함수

#define kthread_run(threadfn, data, namefmt, ...)
({
	struct task_struct *k;

	k = kthread_create(threadfn, data, namefmt, ## __VA_ARGS__);
	if (!IS_ERR(k))
		wake_up_process(k);
	k;
})

커널 스레드는 한번 시작되면 스스로 do_exit() 함수를 호출하거나, 커널의 다른 부분에서 kthread_create()가 반환한 task_struct 구조체의 주소와 함께 kthread_stop() 함수를 호출할 때까지 계속 실행됨

int kthread_stop(struct task_struct *k)

프로세스 종료

프로세스가 종료되면 커널은 프로세스가 가지고 있던 자원 반납 후 부모 프로세스에 자식 프로세스의 종료를 알려줌

일반적으로 프로세스 종료는 자발적 발생
프로세스가 준비됬을 때 명시적으로 exit() 함수를 호출하거나, 프로그램의 main 함수 반환 시에 묵시적으로 exit() 함수가 호출되면서(즉 main 함수를 반환하는 곳에 C 컴파일러가 exit() 함수를 호출하는 코드를 삽입) 종료 작업이 시작됨
물론 프로세스가 비자발적으로 종료되기도 함
위에 경우는 프로세스가 처리할 수도 무시할 수도 없는 시그널이나 예외를 만나는 경우가 해당
어떤 방식으로 프로세스가 종료되든 프로세스를 종료하는 일련의 작업이 kernel/exit.c에 정의된 do_exit() 함수를 통해 진행됨

1. task_struct 구조체의 flags 항목에 PF_EXITING 플래그를 설정함.
2. del_timer_sync() 함수를 호출해 커널 타이머를 제거함. 이 함수가 반환되면, 대기 중인 타이머와 실행 중인 타이머가 없다는 것 보장됨.
3. BSD 방식의 프로세스 정보 기록 기능 사용 시 do_exit() 함수는 acct_update_integrals() 함수를 호출해 관련 정보 기록함.
4. exit_mm() 함수를 호출해 해당 프로세스가 가지고 있는 mm_struct를 반환함. 다른 프로세스에서 이 주소 공간 사용하지 않으면(이 주소 공간 공유되어 있지 않으면) 커널은 해당 자원 해제함.
5. exit_sem() 함수를 호출함. 프로세스가 IPC 세마포어를 얻기 위해 대기하고 있었다면, 이 시점에 대기 상태가 해제됨.
6. exit_files() 및 exit_fs() 함수를 호출해 관련 파일 서술자 및 파일시스템의 참조 횟수를 줄임. 참조 횟수가 0이 되면 해당 객체를 사용하는 프로세스가 없다는 뜻이므로 해당 자원을 반환함.
7. 태스크의 종료 코드를 task_struct의 exit_code 항목에 저장함. exit() 함수에서 지정한 값, 또는 커널의 종료 방식에 의해 종료 코드 값이 결정된다. 이 곳에 저장된 종료 코드 값은 부모 프로세스가 사용할 수 없음.
8. exit_notify() 함수를 호출해 부모 프로세스에 시그널 보내고, 해당 프로세스가 속한 스레드군의 다른 스레드 또는 init 프로세스를 자식 프로세스의 새로운 부모로 설정함. task_struct 구조체의 exit_state 항목에 태스크 종료 상태를 EXIT_ZOMBIE로 설정함.
9. do_exit() 함수는 schedule() 함수를 호출해 새로운 프로세스로 전환함. 이제 이 프로세스는 스케줄링 대상이 아니므로 이 코드가 종료되는 태스크가 실행하는 마지막 코드가 됨. do_exit() 함수는 반환 과정이 없음.

이 시점에서 태스크와 관련된 모든 객체가 반환됨(이 태스크만 해당 자원 사용 시)
이 태스크는 더 이상 실행 가능하지 않고(실행할 주소 공간도 없어짐), EXIT_ZOMBIE 상태가 됨
종료된 태스크가 차지하고 있는 메모리는 커널 스택, thread_info 구조체, task_struct 구조체가 전부다
이제 태스크는 부모 프로세스에 전달이 필요한 정보를 보관하기 위해서만 존재함
부모 프로세스가 해당 정보를 처리하거나 커널이 정보가 더 이상 필요 없다고 알려주면 프로세스가 차지하고 있던 나머지 메모리도 차지하고 있던 나머지 메모리도 반환돼 시스템의 가용 메모리로 돌아감

프로세스 서술자 제거

do_exit() 함수가 완료되고 프로세스가 좀비 상태가 되어 더 이상 실행 가능하지 않더라도 프로세스 서술자는 여전히 남음
이는 종료 후에도 시스템이 자식 프로세스의 정보를 얻을 수 있게 해주기 위함
결국 프로세스 종료를 위한 정리작업과 프로세스 서술자 제거 작업은 분리된 별도의 작업
부모 프로세스가 종료된 자식 프로세스의 정보를 처리하거나 커널이 해당 정보가 필요 없다고 알려주면, 자식 프로세스의 task_struct 구조체에 할당된 메모리가 해제됨

wait() 계열 함수는 하나의 복잡한 wait4() 시스템 호출을 통해 구현되어 있음
기본적인 동작은 함수를 호출한 프로세스의 동작을 자식 프로세스가 종료될 때까지 정지시키는 것, 종료된 자식 프로세스의 PID 값을 반환값으로 가짐
또한 종료된 자식 프로세스의 종료 코드를 저장할 포인터도 제공함

프로세스 서술자에 할당된 메모리를 제거해야 할 때가 되면 release_task() 함수를 호출해 다음 작업을 수행함

1. __exit_signal() 함수를 호출하고, 이 함수는 __unhash_process() 함수를 호출하며, 이어서 detach_pid() 함수에서 해당 프로세스를 pidhash와 태스크 리스트에서 제거함.
2. __exit_signal() 함수는 종료된 프로세스가 사용하던 남은 자원 반환하고, 통계값과 기타 정보를 기록함.
3. 해당 태스크가 스레드군의 마지막 스레드였다면 대표 스레드가 좀비가 된 것이므로, release_task() 함수는 대표 스레드의 부모 프로세스에 이 사실을 알림
4. release_task() 함수는 put_task_struct() 함수를 호출해 프로세스의 커널 스택 및 thread_info 구조체가 들어 있던 페이지를 반환하고, task_struct 구조체가 들어 있던 슬랩 캐시를 반환함

이 시점에서 프로세스 서술자와 해당 프로세스와 연관된 모든 자원이 해제됨

부모 없는 태스크의 딜레마

부모 프로세스가 자식 프로세스보다 먼저 종료된 경우 다른 프로세스를 자식 프로세스의 부모로 지정하는 수단 반드시 필요함
그렇지 않으면, 부모를 잃고 종료된 프로세스는 영원히 좀비 프로세스로 남아 시스템 메모리 낭비하게 됨
해결책은 해당 프로세스가 속한 스레드군의 다른 프로세스를 부모 프로세스로 지정하거나, 이것이 불가능할 경우엔 init 프로세스를 부모 프로세스로 지정하는 것

do_exit() 함수는 exit_notify() 함수를 호출하고, 이 함수에서 forget_original_parent() 함수를 호출함, 여기서 find_new_reaper() 함수를 호출하는데, 이 곳에서 부모 프로세스 재지정이 처리됨

static struct task_struct *find_new_reaper(struct task_struct *father)
{
	struct pid_namespace *pid_ns = task_active_pid_ns(father);
	struct task_struct *thread;

	thread = father;
	while_each_thread(father, thread) {
		if (thread->flags & PF_EXITING)
			continue;
	
	if (unlikely(pid_ns->child_reaper == father))
		pid_ns->child_reaper = thread;
	return thread;
	}

	if (unlikely(pid_ns->child_reaper == father)) {
		write_unlock_irq(&tasklist_lock);
		if (unlikely(pid_ns == &init_pid_ns))
			panic("Attempted to kill init!");

		zap_pid_ns_processes(pid_ns);
		write_lock_irq(&tasklist_lock);

		// child_reaper 항목을 그대로 두거나 그냥 지워버릴 수 없음
		// children 포인터 내용 중에 EXIT_DEAD 상태인 태스크가
		// 들어있을 수 있으므로, forget_original_parent() 함수는
		// 이들을 어딘가로 옮겨야 함

		pid_ns->child_reaper = init_pid_ns.child_reaper;
	}
	return pid_ns->child_reaper;
}

위의 코드는 해당 프로세스가 속한 스레드군의 다른 태스크를 찾아봄
만약 스레드군에 다른 태스크가 없다면 init 프로세스를 찾아서 반환함
위 코드로 새 부모를 찾았으니, 모든 자식 프로세스의 부모 프로세스를 reaper로 다시 지정해주는 작업 필요함

reaper = find_new_reaper(father);
list_for_each_entry_safe(p, n, &father->children, sibling) {
	p->real_parent = reaper;
	if (p->parent == father) {
		BUG_ON(p->ptrace);
		p->parent = p->real_parent;
	}
	reparent_thread(p, father);
}

그 다음 ptrace_exit_finish() 함수를 호출해 추적 기능을 사용하는 자식 프로세스에 대해 마찬가지로 부모 프로세스를 다시 지정해줌

void exit_ptrace(struct task_struct *tracer)
{
	struct task_struct *p, *n;
	LIST_HEAD(ptrace_dead);

	write_lock_irq(&tasklist_lock);
	list_for_each_entry_safe(p, n, &tracer->ptraced, ptrace_entry){
		if (__ptrace_detach(tracer, p))
			list_add(&p->ptrace_entry, &ptrace_dead);
	}
	write_unlock_irq(&tasklist_lock);

	BUG_ON(!list_empty(&tracer->ptraced));

	list_for_each_entry_safe(p, n, &ptrace_dead, ptrace_entry) {
		lsit_del_init(&p->ptrace_entry);
	release_task(p);
	}
}

자식 프로세스 리스트와 추적 리스트 두 리스트가 만들어진 배경이 있음
태스크가 추적 상태에 있는 경우, 해당 프로세스는 디버깅 프로세스를 부모 프로세스로 임시 변경함
그러나 태스크의 원 부모 프로세스가 종료되면, 다른 형제 프로세스와 같이 새 부모 프로세스로 돌아갈 수 있어야 함
이전 커널에서는 이런 조치가 필요한 자식 프로세스를 찾기 위해 시스템의 모든 프로세스 조사함
이에 대한 해결책으로 나온 것이 추적 상태에 있는 자식 프로세스 리스트를 별도로 관리하는 간단한 방법
이를 통해 자식 프로세스를 찾으려고 모든 프로세스 리스트를 뒤지던 작업을 상대적으로 작은 두 개의 프로세스 리스트를 탐색하는 작업으로 줄임

부모 프로세스를 재지정하면, 좀비 프로세스가 남아 있을 위험성 사라짐
init 프로세스는 주기적으로 wait() 함수를 호출해 자신에게 할당된 좀비 프로세스를 정리함